1. Field of the Invention
The present invention relates to a method for transferring sensitive information using initially unsecured communication.
2. Description of Related Art
Certain initially unsecured communication, such as over-the-air communication, often provide great communication flexibility and efficiency as compared to initially secure forms of communication such as dedicated communication channels. Unfortunately, because communication such as over-the-air communication channels are initially unsecured, an attacker can detrimentally disrupt communication between two parties.
In a wireless communication system, the handsets, often called mobiles, purchased by mobile users are typically taken to a network service provider, and long keys and parameters are entered into the handset to activate service. The network of the service provider also maintains and associates with the mobile, a copy of the long keys and parameters for the mobile. As is well-known, based on these long keys and parameters, information can be securely transferred between the network and the mobile over-the-air.
Alternatively, the user receives the long keys over a secure communication channel (e.g., landline or mail), and must manually enter these codes into the mobile.
Because the transfer of the long keys and parameters is performed over a secure communication channel or at the network service provider as opposed to over-the-air, the transfer is secure against over-the-air attacks. However, this method of securely transferring information places certain burdens and restrictions on the mobile user. Preferably, the mobile user should be able to buy their handsets and then get service from any service provider without physically taking the handsets to the provider's location or manually entering long codes. The capability to activate and provision the mobile remotely is part of the North American wireless standards, and is referred to as "over-the-air service provisioning" (OTASP).
Currently, the North American Cellular standard IS41-C species an OTASP protocol using the well-known Diffe-Hellman (DH) key agreement for establishing a secret key between two parties (i.e., for transferring sensitive information) over an initially unsecure communication channel. FIG. 1 illustrates the application of the DH key agreement to establishing a secret key between a mobile and a network used in IS41-C. Namely, FIG. 1 shows, in a simplified form for clarity, the communication between a network 10 and a mobile 20 according to the DH key agreement. As used herein, the term network refers to the authentication centers, home register locations, visiting location registers, mobile switching centers, and base stations operated by a network service provider.
The network 10 generates a random number R.sub.N, and calculates (g R.sub.N mod p). As shown in FIG. 1, the network 10 sends a 512-bit prime number p, a generator g of the group generated by p, and (g R.sub.N mod p) to the mobile 20. Next, the mobile 20 generates a random number R.sub.M, calculates (g R.sub.M mod p), and sends (g R.sub.M mod p) to the network 10.
The mobile 20 raises the received (g R.sub.N mod p) from the network 10 to the power R.sub.M to obtain (g R.sub.M R.sub.N mod p). The network 10 raises the received (g R.sub.M mod p) from the mobile 20 to the power R.sub.N to also obtain (g R.sub.M R.sub.N mod p). Both the mobile 20 and the network 10 obtain the same result, and establish the 64 least significant bits as the long-lived key called the A-key. The A-key serves as a root key for deriving other keys used in securing the communication between the mobile 20 and the network 10.
One of the problems with the DH key exchange is that it is unauthenticated and susceptible to a man-in-the-middle attack. For instance, in the above mobile-network two party example, an attacker can impersonate the network 10 and then in turn impersonate the mobile 20 to the network 10. This way the attacker can select and know the A-key as it relays messages between the mobile 20 and the network 10 to satisfy the authorization requirements. The DH key exchange is also susceptible to off-line dictionary attacks.
Another protocol for transferring sensitive information using initially unsecured communication information initially is the Carroll-Frankel-Tsiounis (CFT) key distribution protocol (See Carroll et. al., Efficient key distribution for slow computing devices: Achieving fast over the air activation for wireless systems, IEEE Symposium on Security and Privacy, May 1998). The CFT key distribution protocol relies on the assumption that one party possesses the public key of certificate authority (CA). For purposes of discussion, this protocol will be described in detail in the context of over-the-air communication between the network 10 and the mobile 20.
A CA is a trustworthy body with its own special key. More specifically, the CA has a public key PK.sub.CA and a secret decrypting key dk.sub.CA. A network service provider, for example, goes to the CA and requests that the CA sign their public key PK.sub.net. Namely, the CA hashes the public key PK.sub.net along with other information, and generates a certificate for the network equal to ENC.sub.dkCA (h(PK.sub.net +other information)), which is the decryption of the hash of PK.sub.net and the other information using an encryption/decryption algorithm ENC and dk.sub.CA as the decryption key. A party with knowledge of PK.sub.CA, then, can encrypt the certificate to obtain the hash of PK.sub.net and the other information. The other information represents any other information the network wants to convey with its public key.
The CFT key distribution protocol will now be described with respect to FIG. 2. FIG. 2 shows, in a simplified form for clarity, the communication between the network 10 and the mobile 20 according to the CFT key distribution protocol. As shown, the network 10 sends its public key PK.sub.net, other information, and the certificate to the mobile 20. Using the public key PK.sub.CA of the CA, the mobile 20 obtains the hash of the public key PK.sub.net plus the other information from the certificate. The mobile 20 also hashes the public key PK.sub.net plus the other information received in the clear from the network 10.
The mobile 20 then verifies the authenticity of the public key PK.sub.net if the result of the hash matches that obtained from the certificate. Having verified the authenticity of the public key PK.sub.net, the mobile 20, using a random number generator disposed therein, generates a first random number as a session key SK and generates a second random number AP for verification purposes. The mobile 20 encrypts the session key SK and the random number AP according to an encryption/decryption algorithm ENC using the public key PK.sub.net. The expression ENC.sub.PKnet (SK, AP) represents this encryption, and sends the encrypted result to the network 10.
The network 10 decodes the output of the mobile 20 using the decrypting key dk.sub.net, associated with the public key PK.sub.net, to obtain the session key SK and the random number AP. As one skilled in the art will appreciate, security requires that only the network 10 have knowledge of the decrypting key dk.sub.net. Next, the network 10 encrypts the A-key, the root key discussed above, and the random number AP according to the encryption/decryption algorithm ENC using the session key SK, and sends the encrypted result to the mobile 20.
Using the session key SK, the mobile 20 decrypts the output of the network 10 to obtain the A-key and the random number AP. The mobile 20 then verifies whether the random number AP decoded from the output of the network 10 matches the random number AP originally sent by the mobile 20 to the network 10. If so, then the mobile 20 accepts the A-key as having come from the network 10, as opposed to an attacker, and follows any known communication protocol (e.g., IS41-C); wherein voice communication eventually takes place via encryption, but not authentication, using keys derived from the A-key. As a next step in the activation process, an encrypted voice channel is established between the mobile 20 and the network 10, and the network service provider requests authorizing information (e.g., credit card information for billing purposes) from the mobile user. Assuming the authorizing information is accepted, then the mobile user is authenticated to the network 10, and service will be provided in the future.
The CFT protocol is not secure if the A-key is repeated for OTASP with the same handset. Suppose a mobile uses its serial number to access the network for OTASP. At this point the attacker blocks the access. Next, the attacker picks a random session key SK and a random number AP and sends them to the network using the blocked mobile's serial number. The network responds with the encrypted A-key which the attacker retrieves, and then the attacker aborts the connection. Now the attacker is in possession of the A-key for that mobile. If the legitimate mobile again accesses the network with its own session key SK and random number AP, the network will again transport the same A-key to the mobile encrypting it with the session key SK from the mobile. Now the mobile will have the A-key and the user on the encrypted voice channel will give authorizing information; thus successfully completing service provisioning. Unfortunately, the attacker already has the A-key, and later he also can use it to make fraudulent calls.
One way of blocking this attack is to make it necessary that the network create a different A-key for every OTASP attempt, even if it originates from the same mobile. The authors of CFT assumed this implicitly, but this must be made explicit because a key distribution protocol should not require such a restriction. If this restriction is added, then the network can not do things like using a pseudo-random function (PRF) to associate an A-key to a mobile or other similar schemes.
Second, a mild form of denial of service attack is possible with the CFT protocol. An attacker substitutes another id number in place of the mobile's true id number throughout the protocol. The protocol will be successful but the network will not have activated the true mobile's id number. Thus, later attempts by the user to access the system will be rejected. This attack is possible because the mobile id number used in communication is not part of the public key encryption of the session key SK and the random number AP sent by the mobile to the network.